Subject: Re: Note from Mike Evans about "TRS clarification request"

From: [email-masked]
Date: Mon, 18 Dec 95 09:30:30 CST

When B goes down and comes back up as an HPR-capable node, it seems that
 the RSN sent to A (about B's TG) would be bumped up by 2 since the
 resource changed.  Then it would *not* be the same as that stored in A's
 topology database (but 2 greater than that what was stored). So, it
 seems to me that the scenario described in the note would not occur;
 i.e., NodeA would discover that the RSN was greater and fall down that
 path of the pseudo-code on page 7-28 of the Architecture Reference
 manual ("If RCVD_RSN (even or odd) > STORED_RSN then").

 Mike does raise some great points in his note. I've added some
 additional comments/answers/suggestions on the topic in the following
 paragraphs...

 In the SNA Formats, there is a statement that *no* reserved fields are
 checked on page 2-3:  "Correct usage of reserved fields is
 enforced by the sender, no receive checks are made on these fields".
 So, it is unclear how a byte-by-byte comparison enforcement would
 work on the TDU fields with this statement in the Formats--maybe, it
 should be looked in to as to possibly modifying the SNA Formats
 Book statement (making it less general)?

 Now with respect to the following question from Mike Evans:
   -If a byte-by-byte comparison is intended, is it reasonable for the
   architecture to assume all products will be consistent in the ordering of
   subfields in originated topology updates and will not reorder the
   subfields in stored and forwarded topology updates?
 On page 7-29 of the Architecture Reference Manual, there's the
 statement: "TDM forwards each received control vector in its entirety".
 However, there does indeed appear to be no statement for the ordering
 of subfields within CV44, CV45, CV46, and CV47--and it seems that this
 type of statement is required for clarity and simplicity. It seems that
 this type of statement should be in the SNA Formats Book in the
 respective control vector defintions (where the imbedded subfields are
 identified)?

 Disclaimer: These are my own opinions and do not necessarily reflect
 the opinion of IBM.

---

From: Bob Clouston <[email-masked]>
Date: Mon, 18 Dec 95 11:29:02 EST

If B does not safe store, or the safe store file was corrupted or removed
by the user, this could happen because B will reset the RSNs, so it could
come back to the same value.

Anything in CV46 subject to change could be affected.  Another candidate
is signalling information in a connection network TG.  If B was taken
down to swap an adapter the new address might not get propagated, so links
through a connection network would fail to activate.

Ordering of subfields should be consistent, but I think the network would
recover if they aren't.  If byte-by-byte comparison fails on an update
with the same RSN, the NN would make the RSN odd and send a TDU.  The resource 
owner would pick this up and bump the RSN to even and send a TDU and all NNs 
would accept the new order.  Specifying an ordering rule would guarantee
these additional flows won't happen in the future becuase of subfield 
reordering.  

Bob Clouston
Cisco Systems